It is known to provide caching in a mobile network. Caching is based on the idea that a large percentage of Internet traffic is repetitive, and that eliminating the sending of repeating content from its origin may offer a savings opportunity in terms of required bandwidth. The main principle of caching in a mobile network is that copies of the repeated content in, for example, the Internet, are moved closer to mobile users. For example, such content may be cached in different parts of the Radio Access Network (RAN), in the Core Network (CN), or just “above” the CN.
The main benefits that can be achieved with caching in mobile networks are as follows:                a. A decrease in the cost of transport in the mobile network as well as the cost for Internet peering. This is achieved “above the cache”, as the cached information in principle is only transferred once in the transmission links above the cache.        b. An improved quality of experience for the mobile end-users. This is mainly achieved with lower delays, as the cached information can be returned faster to the mobile users from the cache (compared to the case where the information is obtained all the way from the original location).        c. Provision of new services, such as content hosting and storage/backup for the operators. A mobile operator can agree with content providers to ensure that the content from a specific content provider is delivered in a better way to the mobile users in the mobile operator's network.        
While the cache can be implemented in various ways in a mobile communication network, there are no satisfactory solutions for interworking between the core network and the cache. For example, there are issues with Lawful interception (LI), charging and policy control. It is therefore difficult to locate a cache (proxy) in a radio network access (Radio base station (RBS), radio network controller (RNC) or similar aggregation point in the backhaul topology below the mobile packet core network nodes such as SGSN, S-GW, PDN-GW/GGSN). The term RNCC (Radio Network- and Cache Controller) is used herein as a generic term that encompasses a current RNC as defined in 3GPP, a future radio access network aggregation and cache control point for 2G, 3G, 4G (LTE), and possible future radio access technologies.
One of the main problems with caching below the core network is that functions such as Lawful Intercept, policy- and charging control are executed in the core network. With a caching solution where user plane traffic is fetched from a cache below the core network, there is currently no solution of how to enforce policy control of the cache, and how to make LI and charging of a subscriber that accesses content that is stored in the cache.
The problem is illustrated in FIG. 1, in which a terminal 1 such as User Equipment (UE) accesses data stored in a cache 2 located at an RNCC 3. The cache 2 comprises a traffic intercept function 4, cache logic 5 and cache storage 6 for storing the cached data. Data is sent from the cache storage 6 to the terminal 1 without traversing the S/P-GW 7. The data is sent between the cache 2 and the terminal 1 via a Radio Base Station (RBS) 8.
LI is a legal requirement enforced on the operators by legal agencies (LEAs, regulatory or administrative agencies), and intelligence services, in accordance with local country laws. A requirement on the mobile packet network system is to be able to copy all packets that the UE 1 receives and transmits to an external system, without any possible way to detect that the traffic is intercepted. Furthermore, all control-events such as handover are reported to the LI-system.
It is a requirement that LI is made per end-user. It is therefore controlled and identified by IMSI, MSISDN. However, the RAN does not usually have knowledge of IMSI, MSISDN.
LI also requires passive copying of all packets sent to or from the UE to the LI system. All user plane data is seen by Core Network Gateways (e.g. SGSN, GGSN) and the gateway's traffic intercept function sends the user plane data to the LI-system. However, the core network (at which the gateways are located) does not see traffic from the RAN cache.
Reporting of control-plane events is also a requirement for LI, such as handovers and establishment of RABs. However, a cache does not produce any important control-events so it should not be anything specific to report for LI.
LI is configured by an Operation and Maintenance system (OAM) and interfaces with nodes such as the SGSN, S-GW and P-GW/GGSN. However, the LI control signalling such as activate LI for a user can not be sent forward from core network nodes. The RAN does not have knowledge about user identities.
LI should not be traceable by the end-user. No changes are allowed in the perceived network characteristics due to LI. Disconnecting or modifying operations for the cache due to LI is not a feasible solution because a different performance could be measured by the end-user.
The above problems all arise for LI when interworking with a cache in a mobile communication network.
Further problems with interworking with the cache arise from charging requirements. Charging is made per end-user, and therefore controlled by the IMSI and the MSISDN. However, the RAN system does not have knowledge of the IMSI and the MSISDN
Volume counting is made separately in the uplink and downlink, and so subscribers' traffic volume is counted in the core network (SGSN, S-GW, P-GW). Traffic between the cache and a UE 1 does not traverse any of these nodes and so will not be counted.
For roaming charging, accounting records are exchanged between operators at roaming, the volumes are counted in the uplink and downlink separately and used for billing. The accounting between the operators is different from subscriber charging. This is a separate charging problem that has to be addressed. Volume charging for end-users is made as a sum for uplink/downlink. On-line charging is typically used for pre-paid services with a maximum traffic quota (buckets). When the end-user has reached maximum traffic limit, the cache should stop or throttle the traffic from the cache to the subscriber. Off-line charging is mainly to support billing on Charging Data Records (CDRs) which are generated by the S-GW/PDN-GW/GGSN. The off-line charging works by counting user plane traffic volume which is stored in the subscriber's monthly traffic bucket. Service based charging is made per-URL and/or IP-address range.
If the operator applies Service based charging, an additional compensation of the subscribers “traffic quota” may be needed. In one scenario, an end-user has a subscription to the content provider who pays for the end-users access of the content.
It can be seen that there are issues in capturing the relevant data for both LI and charging when using a cache at the RNCC 3, as the data from the cache typically does not traverse any nodes that normally have interfaces for such functions.